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ABSTRACT 


This  study  addressed  the  role  of  the  US  Army  Training  and  Doctrine  Command, 
as  the  Army's  principal  Combat  Developer,  in  planning  for  and  providing 
post-deployment  software  support  (PDSS)  to  battlefield  automated  systems  (BAS). 
The  Study  was  a  three-phase  effort  directed  toward  defining  a  viable,  feasible, 
and  cost  effective  functional  and  management  structure  for  the  Combat 
Developer  to  provide  PDSS  for  BAS,  within  the  framework  of  Army  doctrine 
and  policy,  the  Post-Deployment  Software  Support  Concept  Plan  for  Battlefield 
Automated  Systems,  and  the  related  functional  requirements  of  the  Combat 
Developer. 

The  Phase  I  effort  was  conducted  to  identify  and  describe  the  current  macro¬ 
management  level  and  battlefield  functional  area  (BFA)  level  PDSS  structure 
and  processes,  relate  these  processes  to  other  Combat  Developer  functions, 
and  identify  the  Combat  Developer's  PDSS  requirements,  regulatory  and  direc¬ 
tive  authority,  and  the  BAS  that  must  be  supported.  Phase  I  results  were 
documented  in  the  First  Interim  Technical  Report,  Volume  II,  30  September  1980. 

The  Phase  II  effort  was  directed  toward  defining  three  TRADOC  functional  and 
management  PDSS  systems.  The  first  of  these  systems,  the  Baseline  System, 
was  developed  from  information  gathered  and  analyzed  during  Phase  I.  The 
description  of  this  system  identifies  currently-authorized  resources,  and 
also  projects  resource  requirements  needed  to  accomplish  future  PDSS  using 
the  present  macro-  and  BFA-level  structure.  Next,  a  Theoretical  System,  un¬ 
constrained  by  resources,  was  described  which  would  accommodate  all  identi¬ 
fied  Combat  Developer  PDSS-related  functions.  Finally,  a  Hybrid  System  was 
described  recognizing  the  realities  of  current  organizational  structures  and 
their  functional  responsibilities.  These  three  systems  were  designed  to 
provide  a  basis  for  TRADOC  to  either  select  or  derive  a  preferred  alternative. 
Phase  II  results  were  documented  in  the  Second  Interim  Technical  Report, 

Volume  III,  16  December  1980. 

Phase  III  of  this  study  provided  an  Implementation  Plan  for  transitioning 
from  the  present  situation  to  the  Objective  (preferred)  System  derived  by 
TRADOC  from  the  alternatives  presented  in  Phase  II.  Also  included  is  a  des¬ 
cription  of  the  proposed  Objective  System.  Phase  III  results  were  documented 
in  the  Third  Interim  Technical  Report,  Volume  IV,  31  January  1981. 

This  Executive  Summary  and  Final  Report,  Volume  I,  28  February  1981,  provides 
an  overview  of  the  entire  study  as  described  in  the  First,  Second  and  Third 
Interim  Reports.  This  report  includes  assumptions  and  methodology  used,  as 
well  as  conclusions  and  recommendations  reached. 
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EXECUTIVE  SUMMARY 


1.  INTRODUCTION. 

a.  General ■  The  US  Army  has  spent,  is  spending,  and  will  spend  many 
billions  of  dollars  on  sophisticated  battlefield  systems  to  improve  the  cap¬ 
abilities  and  effectiveness  of  our  ground  forces.  The  automated  components 
of  many  of  these  systems  have  increased  rapidly  in  just  a  few  years  to  the 
point  where  automation  represents  a  very  substantial,  and  in  some  cases  the 
major,  portion  of  system  costs.  The  military  value  of  such  systems,  in  terms 
of  combat  effectiveness  and  combat  readiness,  cannot  be  realized  unless 
individual  systems  perform  as  intended  by  the  user  and  the  many  interdepend¬ 
ent  systems  interoperate  as  an  integrated  whole.  Achievement  of  such  objec¬ 
tives  is  a  problem  of  system  planning,  integration,  management,  and  support-- 
throughout  the  system  life  cycle.  Because  of  the  increasing  role  of  automa¬ 
tion  and  greater  interdependence  among  battlefield  automated  systems,  re¬ 
solution  of  this  problem  calls  for  new  approaches  and  orientations  in  the 
system  development  and  life  cycle  management  process.  Organization,  re¬ 
sources,  and  procedures  are  all  impacted.  The  US  Army  Training  and  Doctrine 
Command  (TRADOC)  is  taking  steps  to  address  this  problem  and  identify  and 
implement  necessary  changes,  in  concert  with  other  Combat,  Materiel,  and 
System  Developers.  This  TRADOC  study  addresses  a  critical  part  of  this  total 
problem--that  part  dealing  with  post-deployment  software  support  (PDSS). 

b.  The  PDSS  Requirement.  The  requirement  to  provide  PDSS  to  the  growing 
number  of  battlefield  automated  systems  (BAS)  projected  to  enter  the  Army 
inventory  during  the  next  several  years  is  one  of  increasing  concern  within 
the  Army.  The  Users,  Materiel  Developer  (MD),  and  Combat  Developer  (CD)  all 
have  essential  roles  in  the  total  effort  to  provide  effective  PDSS  for  BAS. 
TRADOC,  as  the  Army's  principal  CD  and  the  "battlefield  architect",  is 
responsible  for  determining  what  capability  is  required  and  when  it  is  re¬ 
quired.  The  magnitude  and  complexity  of  fulfilling  this  responsibility, 
especially  with  respect  to  automated  systems,  necessitates  that  tne  CD 
interact  closely  with  both  the  User  and  MD  to  ensure  that  MD  capabilities 
are  fully  employed  and  User  requirements  are  satisfied  to  the  maximum 

extent  possible.  This  CD  responsibility  applies  to  initial  system  development 
and  to  any  subsequent  post-deployment  changes  to  a  system.  In  carrying  out 
this  role,  the  CD  must  be  a  driver,  innovator,  and  active  representative  of 
all  Field  Users. 

2.  PURPOSE.  The  purpose  of  this  three-phase  study  was  to  define,  in  detail, 
a  viable,  feasible,  and  cost  effective  functional  and  management  structure 
through  which  the  CD  can  fulfill  his  role  in  providing  PDSS  for  BAS  within 
the  framework  of  Army  doctrine  and  policy,  the  Army  PDSS  Concept  Plan 

for  BAS  and  the  related  functional  requirements  of  the  CD. 


3.  DISCUSSION. 


a .  Background. 

(1)  Requirement  for  an  Army-Wide  PDSS  System.  Recognizing  the  in¬ 
creasing  importance  of  PDSS,  the  US  Army  Materiel  Development  and  Readiness 
Command  (DARCOM)  initiated  a  study  in  July  1978,  in  accordance  with  guidance 
from  the  US  Army  Vice  Chief  of  Staff,  directed  toward  developing  a  concept 
for  a  systematic  approach  to  planning  for  and  providing  PDSS  for  BAS  on  an 
Army-wide  basis.  Within  DARCOM,  the  Communications  Research  and  Development 
Command  (CORADCOM)  was  tasked  with  primary  responsibility  for  that  study. 

A  task  force  of  representatives  from  the  Army  Staff  and  several  Army  commands 
was  formed  to  assist  CORADCOM  in  this  effort.  Results  of  the  effort  are 
documented  in  a  report  entitled  PDSS  Concept  Plan  for  BAS,  May  1980.  Both 
DARCOM  and  TRA00C  have  concurred  in  that  report  which  has  been  forwarded  to 
Headquarters,  Department  of  the  Army  (HQDA)  for  approval. 

(2)  Approach  selected  to  satisfy  the  requirement.  The  task  force 
that  conducted  the  DARCOM- ini tiated  study  considered  several  alternative 
approaches  for  providing  PDSS  to  the  large  number  of  BAS  projected  for 
deployment  over  the  next  several  years.  The  approach  selected  and  documen¬ 
ted  in  the  PDSS  Concept  Plan  cited  above,  focuses  on  the  battlefield  func¬ 
tional  area  (BFA)  concept  since  it  is  within  each  BFA  that  the  doctrinal, 
functional,  and  technical  dependencies  and  interoperability  needs  are  the 
greatest.  Figure  1  illustrates  the  major  elements  currently  considered  to 

be  included  in  the  BFA  concept.  In  consonance  with  this  concept,  an  approach 
called  the  "Hybrid  Approach"  was  selected.  This  approach  calls  for  MD- 
managed  PDSS  centers  to  be  located  at  five  TRADOC  doctrinal  centers/schools 
and  six  materiel  development  commands.  This  approach  recognizes  both  the 
doctrinal  sensitivity  of  certain  BAS  and  the  inherently  technical  complexity 
of  others.  This  approach  requires  a  case-by-case  review  of  systems  and  a 
separate  decision  as  to  the  optimal  location(s)  for  fielded  software  support 
for  each.  This  approach  is  designed  to  achieve  the  software  support  benefits 
resulting  from  BFA  orientation  while  recognizing  the  realities  of  current 
organizational  structures  of  DARCOM  and  TRADOC,  and  the  Functional  respon¬ 
sibilities  of  the  US  Army  Intelligence  and  Security  Command  (INSCOM),  the 
US  Army  Communications  Command  (USACC),  and  the  US  Army  Computer  Systems 
Command  (USACSC). 

(3)  Concept  for  Materiel  Developer  and  Combat  Developer  facilities. 

The  hybrid  approach,  discussed  above,  recognizes  the  need  for  both  MD  and  CD 
facilities  for  PDSS.  The  number  and  location  of  MD  facilities  are  addressed 
specifically  in  the  PDSS  Concept  Plan  for  BAS;  however,  CD  facilities  are 
only  addressed  conceptually. 

(a)  Materiel  Developer  facilities.  With  respect  to  MD  facilities, 
the  plan  recommends  the  establishment/maintenance  of  11  PDSS  software  support 
centers  as  shown  in  Figure  2.  As  indicated  in  the  figure,  four  of  these 
centers  are  currently  operational,  although  some  expansion  may  be  desirable 


Figure  1.  Elements  of  the  battlefield  functional  area  concept 


MATERIEL  DEVELOPER  PDSS  CENTERS 


CENTER 

LOCATION 

MANAGED  BY 

1 

PICATIKNY  ARSENAL 

ARRADCOM 

2 

FORT  MONMOUTH 

CORADCOM 

3 

FORT  LEAVENWORTH 

CORADCOM 

4 

FORT  BELVOIR* 

CSC 

5 

FORT  LEE* 

CSC 

6 

FORT  BLISS* 

MI  COM 

7 

FORT  SILL* 

CORADCOM 

8 

FORT  HUACHUCA 

ERADCOM 

9 

FORT  MONMOUTH 

ERADCOM 
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The  establishment  of  PDSS  centers  at  Fort  Bliss,  Fort  Sill,  Fort  Leavenworth, 
and  Fort  Huachuca,  as  provided  for  in  the  PDSS  Concept  Plan  for  BAS,  satisfies 
TRADOC's  requirement  that  the  PDSS  centers  for  executive/control  systems  be 
located  with  the  CD  to  provide  synergism  between  the  Combat  and  Materiel 
Developers. 


(b)  Combat  Developer  facilities.  The  PDSS  Concept  Plan  for 
BAS  outlines  a  concept  for  establishing  CD  facilities  to  provide  for  the  close 
and  continuous  relationship  which  must  exist  between  the  CD  and  MD  throughout 
a  system's  life  cycle.  This  concept  calls  for  the  designation  of  Combat 
Development  System  Managers  (CDSM)  and  the  establishment  of  Combat  Development 
Support  Facilities  (CDSF)  as  determined  to  be  needed  by  TRADOC.  The  defini¬ 
tions  of  these  terms  are  presented  below,  as  developed  during  this  current 
study  effort. 


1.  Combat  Development  System  Manager  (CDSM).  CDSM  is  a 
term  used  to  identify  the  member  of  TRADOC  who  is  assigned  primary  respon¬ 
sibility  as  the  software  Combat  Developer  and  the  principal  Field  User's 
representative  for  PDSS  of  a  designated  system  or  group  of  systems  within 

a  BFA.  The  CDSM  is  responsible  for  managing/conducting  and  coordinating  all 
software-related  actions  inherent  in  the  CD  mission.  A  CDSM  will  be  desig¬ 
nated  by  the  commander  of  the  responsible  center  or  school  for  every  BAS  for 
which  TRADOC  has  proponency,  prior  to  the  attainment  of  Milestone  II  in  the 
system  life  cycle.  The  CDSM  will  normally  remain  in  existence  until  the 
system(s)  for  which  he  is  responsible  are  phased  out  of  operation.  The  CDSM 
may  be  any  combat  developments  staff  officer  deemed  to  be  capable  of  ful¬ 
filling  the  responsibilities  of  the  COS  for  a  given  system  or  systems. 

This  could  be  a  TRADOC  System  Manager  (TSM)  or  a  member  of  the  TSM's  staff 
if  desired,  but  more  likely  a  member  of  the  combat  developments  staff. 

2.  Combat  Development  Support  Facility  (CDSF).  CDSF  is 
a  term  used  to  identify  the  collection  of  facilities,  equipment,  personnel, 
and  operating  procedures  which  provide  a  CD  focal  point  for  addressing  PDSS 
and  related  matters  and  together  represent  the  capability  of  a  TRADOC  inte¬ 
grating  or  functional  center  to  fulfill  its  responsibilities  in  planning  and 
providing  PDSS  for  BAS.  This  embodiment  of  the  Combat  Developer's  PDSS  cap¬ 
ability  may  exist,  in  whole  or  in  part,  at  a  specific  location  on  a  continuous 
basis  as  a  specifically  identified  part  of  the  TRADOC  center's  organizational 
structure  or  may  be  formed  on  an  ad  hoc  basis  from  resources  integral  to 
various  organizational  elements  of  the  center.  The  prominence  and  permanency 
of  CDSFs  may  vary  among  TRADOC  integrating  and  functional  centers  depending 
upon  differences  in  the  magnitude  of  PDSS  requirements  and  local  organization¬ 
al  structure  and  operating  procedures.  The  nature  of  the  CDSF  at  any  given 
center  may  also  vary  from  time  to  time  depending  upon  changes  in  PDSS  require¬ 
ments,  e.g.,  changes  in  the  number  or  life  cycle  stage(s)  of  battlefield 
automated  systems  for  which  the  center  has  proponency. 


(4)  Implementation.  Both  DARCOM  and  TRADOC  are  proceeding  with 
actions  directed  toward  the  further  development  and  implementation  of  the 
concept  plan  cited  above.  This  study  represents  the  initial  implementation 
within  TRADOC. 

b.  Objectives. 

(1) .  Overall  Study.  The  objective  of  this  study  was  to  define,  in 
detail,  a  viable,  feasible,  and  cost  effective  functional  and  management 
structure  through  which  the  CD  can  fulfill  his  role  in  planning  and  providing 
PDSS  for  BAS  within  the  framework  of  Army  doctrine  and  policy,  the  Army  PDSS 
Concept  Plan  for  BAS  and  the  related  functional  requirements  of  the  CD.  While 
the  PDSS  Concept  Plan  for  BAS  provides  a  basic  conceptual  framework  for  CD 
participation  in  PDSS,  the  concept  must  be  defined  in  greater  detail  to 
provide  a  basis  for  implementation  planning  within  TRADOC. 

(2)  Phase  I.  The  objective  of  Phase  I  was  to  gain  a  better  under¬ 
standing  of  PDSS  requirements  by  identifying  and  describing  the  macro-manage¬ 
ment  level  and  BFA  level  PDSS  processes,  associating  these  with  the  other 

CD  functions,  and  identifying  the  Combat  Developer's  PDSS  requirements,  all 
within  the  context  of  the  PDSS  Concept  Plan  for  BAS. 

(3)  Phase  II.  The  objective  of  Phase  II  was  to  develop  alternative 
TRADOC  systems  for  fulfilling  the  CD's  responsibilities  for  planning  and 
providing  PDSS  for  BAS.  In  pursuit  of  this  objective,  the  Baseline  System 
and  two  alternatives  were  defined.  These  alternatives  were  called  the 
Theoretical  System,  representing  a  potentially  achievable  ideal,  and  the 
Hybrid  System,  based  on  a  comparison  of  the  Theoretical  and  Baseline 
Systems.  These  alternatives  were  designed  to  provide  a  basis  for  TRADOC 

to  either  select  or  derive  a  preferred  alternative. 

(4)  Phase  III.  The  objective  of  Phase  III  was  to  integrate  the 
results  of  Phases  I  and  II  into  an  implementation  plan  for  the  system 
selected  by  TRADOC.  Achievement  of  this  objective  required  the  development 
of  a  detailed  description  of  the  preferred  TRADOC  PDSS  functional  and  manage¬ 
ment  structure  resulting  from  Phase  II,  and  a  plan  for  transitioning  from  the 
present  to  implementation  of  the  preferred  system. 

c.  Scope. 

(1)  General .  This  study  focused  upon  TRADOC's  role  as  the  Army's 
principal  CD  in  planning  for  and  providing  PDSS  for  BAS.  Responsibility  for 
PDSS  for  individual  BAS  corresponds  with  the  assignment  of  TRADOC  proponency 
for  each  system.  The  categorization  of  BAS  developed  during  the  DARCOM-in- 
itiated  PDSS  study,  was  also  used  in  this  study.  This  categorization  divided 
BAS  as  shown  below: 

• 


Category  1  -  large  evolutionary  systems 
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•  Category  2A  -  small  evolutionary  systems 

•  Category  2B  -  large  stable  systems 

•  Category  3  -  small  stable  systems. 

Primary  focus  in  this  study  was  on  Category  1  and  2  BAS  in  accordance  with 
Study  Advisory  Group  (SAG)  guidance.  Appendix  C  of  Volume  IV,  Third  Interim 
Technical  Report,  lists  all  BAS  addressed  in  each  BFA  and  identifies  the 
TRADOC  proponent  for  each. 

(2)  Definitions.  Key  definitions  are  listed  below  to  further 
clarify  this  scope. 

(a)  Post-Deployment  Software  Support  (PDSS)  is  that  part  of 
overall  system  support  necessary  to  sustain,  modify,  and  improve  a  deployed 
system's  computer  software,  as  defined  by  the  User  or  his  representative. 

It  includes  evaluation,  development,  and  timely  implementation  of  system  and 
software  modifications  to  accommodate  trouble  reports;  User  proposed  changes; 
and  changes  to  satisfy  new  or  revised  doctrinal,  tactical,  procedural  or 
interoperability  requirements.  (Source:  PDSS  Concept  Plan  for  BAS,  May  1980) 

(b)  Battlefield  Automated  System  (BAS)  is  a  system  which  con¬ 
tains  a  computer(s),  is  intended  for  use  by  the  Army  in  the  field,  and  which 
will  not  function  without  computer(s);  e.g.,  AN/TSQ-73,  TACFIRE.  (Source: 
Assistant  Secretary  of  the  Army  (RD&A),  Memorandum  for  the  Deputy  Chief  of 
Staff  for  Research,  Development,  and  Acquisition,  1  July  1980) 

(c)  Battlefield  Functional  Area  (BFA)  is  a  conceptual  grouping 
of  Army  personnel,  equipment,  and  procedures  which  together  perform  a  major 
battlefield  function.  The  BFAs  used  in  this  study  were  identified  in  Figure 
1.  TRADOC  proponency  for  each  BFA  is  shown  in  Figure  3.  (Derived  from 
Functional  Systems  on  the  Corps  Battlefield,  US  Army  Combined  Arms  Combat 
Development  Activity,  13  July  1978) 

(3)  Relationship  of  PDSS  and  the  system  life  cycle.  Planning  for 
and  provision  of  PDSS  must  be  accomplished  as  an  integral  part  of  system 
development  and  life  cycle  management.  The  CD's  PDSS  planning  effort  begins 
with  participation  in  preparation  of  the  Computer  Resources  Management  Plan 
(CRMP)  during  the  Conceptual  Phase  as  illustrated  in  Figure  4.  Also  shown 
is  the  period  when  CD  PDSS  actions  may  occur.  The  time  will  vary  among 
systems  but  it  is  generally  accepted  that  CD  PDSS-type  actions  may  be  re¬ 
quired  any  time  after  the  system  software  configuration  is  frozen  for 
engineering  development,  and  may  continue  throughout  the  remainder  of  the 
system  life  cycle.  Any  changes  before  the  system  software  configuration 

is  frozen  are  considered  to  be  part  of  system  development,  not  PDSS.  For 
those  systems  being  developed  under  the  evolutionary  concept  authorized  by 
DOD  Instruction  5000.2,  PDSS  planning  must  begin  early  in  the  conceptual 
stage.  PDSS  actions  for  these  evolutionary  systems  will  be  required  begin¬ 
ning  with  the  deployment  of  the  initial  developmental  version. 
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(4)  Classification.  Contract  No.  MDA903-80-C-0479  under  which  this 
study  is  being  conducted  states  that,  “The  highest  classification  involved 
in  the  performance  of  this  contract  is  SECRET".  No  system  whose  existence 
is  classified  within  this  level  was  identified  to  the  study  team  during  the 
Phase  I  or  II  research  efforts.  If  there  are  systems  whose  existence  is 
classified  above  the  SECRET  level,  TRADOC  PDSS  requirements  associated  with 
such  systems  must  be  identified  and  addressed  separately. 

d.  Assumptions. 

(1 )  Missions  and  PDSS  Roles. 

(a)  The  mission  and  basic  role  of  the  MD  with  respect  to  PDSS 
will  remain  essentially  as  described  in  the  PDSS  Concept  Plan  for  BAS,  May 
1980. 


(b)  The  mission  and  basic  role  of  the  CD  with  respect  to  PDSS 
will  remain  essentially  as  described  in  the  PDSS  Concept  Plan  for  BAS,  May 
1980,  and  the  First  Interim  Technical  Report  of  the  Assessment  of  the  Combat 
Developer's  Role  in  Post-Deployment  Software  Support,  Volume  II,  30  September 
1980. 


(c)  The  major  functional  responsibilities  of  TRADOC  centers  and 
schools  will  remain  essentially  as  specified  in  TRADOC  Reg.  10-41  and  the  re¬ 
spective  center  and  school  organization  and  functions  regulations. 

(2)  PDSS  Centers.  Materiel /System  Developer-managed  PDSS  centers 
will  be  established  as  recommended  in  the  PDSS  Concept  Plan  for  BAS,  May  1980. 
The  11  recommended  centers  were  identified  in  Figure  2. 

(3)  BAS.  BAS  addressed  in  this  report  will  continue  to  be  developed 
and  enter  the  Army  inventory  through  1987,  generally  as  currently  projected. 

e.  Methodology. 

(1)  Study  Structure.  This  study  was  completed  through  the  accom¬ 
plishment  of  eight  tasks  over  an  eight  month  period  divided  into  three  phases 
as  shown  in  Figure  5.  The  study  began  30  June  1980  and  was  completed  28 
February  1981. 

(2)  Phase  I.  Phase  I  began  upon  contract  award.  It  consisted  of 
Tasks  1  through  4.  It  addressed  the  current  structure  and  processes  within 
the  Army  at  the  macro-  and  BFA-levels  for  performing  PDSS,  and  identified  the 
Combat  Developer's  PDSS  requirements  at  the  BFA  level.  The  methodology  em¬ 
ployed  involved  data  collection,  analysis,  and  documentation  efforts.  Data 
collection  was  accomplished  through  (a)  an  extensive  literature  review  and 
research  effort;  (b)  visits  to  18  Army  organizations  including  elements  of 
the  Army  Staff,  Headquarters,  US  Army  Training  and  Doctrine  Command  (TRADOC), 
five  other  major  commands  and  field  operating  agencies,  and  eight  TRADOC 
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centers  and  schools;  and  (c)  developing  and  administering  a  questionnaire 
designed  to  obtain  detailed  information  on  the  BAS  being  addressed.  These 
data  were  then  collated  and  analyses  of  the  macro-  and  BFA-level  PDSS  pro¬ 
cesses  were  developed.  A  description  was  also  developed  of  TRADOC's  PDSS 
requirements  as  perceived  by  elements  of  TRADOC  Centers  responsible  for 
performing  the  Combat  Developer's  functions  in  providing  PDSS  to  BAS.  Re¬ 
sults  of  Phase  I  were  documented  in  Volume  II,  First  Interim  Technical  Report 
on  the  Assessment  of  the  Combat  Developer's  Role  in  PDSS,  30  September  1980. 

(3)  Phase  II.  Phase  II  of  the  study,  documented  in  Volume  III, 

Second  Interim  Technical  Report  and  consisting  of  Tasks  5,  6,  and  7,  was 
directed  toward  the  definition  of  the  TRADOC  Baseline  PDSS  System  and  two 
alternative  TRADOC  PDSS  models  or  systems  that,  if  implemented,  would  pro¬ 
vide  TRADOC  a  better  capability  to  accomplish  its  PDSS  role.  These  systems 
were  developed  from  the  PDSS  information  gained  during  Phase  I,  from  SAG 
member  feedback,  and  from  further  analysis  and  research  during  Phase  II. 

The  methodology  followed  in  Phase  II  is  illustrated  in  Figure  6.  As  indicated, 
a  written  description  of  the  Baseline  System  was  prepared  first,  as  a  basic 
point  of  reference.  One  of  the  two  alternative  systems,  called  the  Theoretical 
System,  was  then  designed  to  satisfy  all  CD  PDSS  responsibilities,  without 
reference  to  any  resource  constraints  except  that  it  be  a  potentially  achiev¬ 
able  alternative.  This  Theoretical  System  was  structured  and  a  written  de¬ 
scription  was  prepared,  working  primarily  from  the  BFA  center  level  upwards. 
Then  the  Baseline  and  Theoretical  Systems  were  compared  and  analyzed  for 
insights  on  which  to  base  the  second  of  the  two  alternative  systems,  called 
the  Hybrid  System.  Results  of  Phase  II  were  presented  at  the  SAG  Meeting, 

17-18  December  1980.  The  principal  purpose  of  the  SAG  meeting  was  to  review 
the  system  descriptions  and  either  select  or  derive  a  final  alternative  system 
for  use  in  Phase  III  so  that  an  implementation  plan  could  be  formulated  for 
transitioning  from  the  present  to  the  desired  capability. 

(4)  Phase  III.  Following  receipt  of  guidance  from  the  Phase  II  SAG 
meeting,  the  Phase  III  study  effort  proceeded.  The  Phase  III  effort  was 
devoted  to  the  development  of  the  design  and  a  description  of  the  "Objective" 
PDSS  System,  and  a  plan  which  would  provide  for  transition  from  the  present 
to  implementation  of  the  selected  alternative  model.  This  Objective  System 
design  and  the  implementation  plan  are  documented  in  Volume  IV,  Third  Interim 
Technical  Report. 

(5)  Executive  Summary  and  Final  Report.  The  Statement  of  Work 
called  for  an  Executive  Summary  and  Final  Report  to  be  prepared  and  submitted 
in  draft  on  31  January  1981.  Following  TRADOC  review,  this  report  was  revised 
and  submitted  in  final  copy  on  28  February  1981.  This  Executive  Summary  and 
Final  Report  contains  appropriate  introductory  and  background  information, 

a  discussion  of  the  methodology,  relevant  information  from  the  three  Interim 
Technical  Reports  to  include  a  brief  description  of  the  TRADOC  Objective 
PDSS  System,  and  a  discussion  of  the  proposed  implementation  plan  for  transi¬ 
tioning  from  the  current  situation  to  th°  objective  system. 
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f.  Study  Documentation.  As  indicated  in  Paragraph  3.e.  and  in  Figure 
5,  results  of  this  study  are  documented  in  four  volumes  as  follows: 

•  Volume  I  -  Executive  Summary  and  Final  Report  (this  document) 

•  Volume  II  -  First  Interim  Technical  Report,  30  September  1980 

•  Volume  III  -  Second  Interim  Technical  Report,  16  December  1980 

•  Volume  IV  -  Third  Interim  Technical  Report,  31  January  1981 

g.  Analysis.  This  paragraph  contains  a  discussion  of  the  significant 
aspects  of  the  research  and  analyses  conducted  during  Phases  I,  II,  and  III, 
of  the  Study.  This  discussion  is  presented  generally  in  the  sequence  in 
which  the  work  was  accomplished. 

(1 )  Phase  I. 

(a)  General .  Phase  I  was  focused  on  research  and  analysis 

of  current  macro-management  level  and  BFA-level  PDSS  processes,  and  on  identi¬ 
fication  of  TRADOC's  PDSS  responsibilities  and  functional  requirements.  The 
effort  devoted  to  these  areas  and  significant  aspects  of  the  results  obtained 
are  discussed  below. 

(b)  Macro-management  level  and  BFA-level  analyses.  These 
analyses  were  directed  toward  identifying  the  macro-  and  BFA-level  organi¬ 
zations  that  have  PDSS  responsibilities  and  developing  descriptions  of  the 
processes  through  which  the  planning  for  and  provision  of  PDSS  to  BAS  are 
accomplished.  Research  conducted  revealed  that  PDSS  is  addressed  to  a  very 
limited  degree  in  current  Army  regulatory  documents  and  organizational  charters. 
To  the  extent  that  it  is  addressed,  it  is  discussed  as  an  integral  part  of 

the  system  acquisition  and  life  cycle  management  process.  Thus,  while  this 
effort  focused  on  PDSS  functional  responsibilities  and  associated  processes, 
it  was  necessary  to  examine  the  broader  functional  areas  of  system  acquisition 
and  life  cycle  management  in  order  to  identify  implicit  PDSS  responsibilities 
of  macro-  and  BFA-level  organizations.  The  results  of  this  effort  are 
discussed  in  three  general  areas: 

•  The  macro-  and  BFA-level  organizational  elements  involved, 

•  Applicable  regulatory  policies  and  procedures,  and 

t  The  battlefield  automated  systems  supported. 

1_.  Macro-management  level  analysis. 


a.  Organizations  involved.  The  organizational  elements 
at  the  macro-management  level  with  principal  responsibilities  related  to  PDSS 
are  identified  in  Figure  7  and  discussed  briefly  below.  Only  those  organiz- 
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ations  with  major  responsibilities  are  addressed  since  the  inclusion  of  other 
organizations  with  minor  or  supporting  PDSS  roles  would  contribute  little  to 
this  report.  More  detail  on  the  roles,  responsibilities,  relationships ,  and 
operating  procedures  of  the  organizations  identified  is  presented  in  Paragraphs 
2-3  and  2-4  of  Volume  II,  First  Interim  Technical  Report. 

b_.  Role  of  the  macro-management  level  structure.  The 
role  of  the  Army  macro-management  level  structure  with  respect  to  PDSS  for 
BAS  is  primarily  one  of  establishing  and  promulgating  applicable  Dolicy  and 
guidance,  and  acquiring  and  allocating  resources  necessary  to  provide  effec¬ 
tive  post-deployment  support  to  battlefield  systems.  This  role  is  carried 
out  at  the  Headquarters,  Department  of  the  Army  and  major  command  levels. 

No  significant  gaps  or  duplications  were  identified  among  the  mission/ 
responsibility  statements  of  these  macro-management  level  organizations.  No 
changes  appear  to  be  needed  in  organizational  missions  pertaining  to  systems 
acquisition  and  life  cycle  management  at  the  macro-management  level.  However, 
AR  10-5:  Organization  and  Functions-Department  of  the  Army,  needs  to  he  re¬ 
vised  and  republished  to  reflect  the  current  responsibilities  of  the  Assistant 
Chief  of  Staff  for  Automation  and  Communications  (ACSAC)  and  the  relationship 
between  the  ACSAC,  Deputy  Chief  of  Staff  for  Research,  Development,  and  Acqui¬ 
sition  (DCSRDA),  the  Deputy  Chief  of  Staff  for  Operations  and  Plans  (DCSOPS), 
and  the  Army  Force  Modernization  Coordination  Office,  in  the  Army  automation 
functional  area.  In  general,  the  current  missions  and  functions  of  the  Army 
Staff  and  Major  Commands  (MACOMs)  form  an  acceptable  framework  for  developing 
an  effective  PDSS  system  for  BAS. 

2.  BFA-level  analysis.  TRADOC  is  organized  the  way  the 
Army  fights--by  battlefield  functional  area.  In  consonance  with  this 
structure,  the  Study  Team  addressed,  by  battlefield  functional  area,  the  or¬ 
ganizations  within  TRADOC  that  have  key  roles  in  planning  for  or  providing 
PDSS  for  BAS.  Figure  1  identified  the  major  components  of  this  BFA  concept. 
Figure  8  shows  these  same  BFA  components  and  identifies  the  principal  TRADOC 
organizations  within  each  BFA.  Each  of  these  areas  is  discussed  briefly  in 
the  paragraphs  that  follow.  Details  relative  to  the  way  in  which  the  organ¬ 
izations  in  each  area  operate  at  present  in  planning  for  and  providing  PDSS 
to  BAS  is  discussed  in  Paragraph  2-4,  Functional  Area  Analysis,  of  Volume  II, 
First  Interim  Technical  Report. 

a_.  Force  Level  Control.  As  indicated  in  Figure  8, 

Force  Level  Control  is  not  one  of  the  five  recognized  BFAs,  but  rather  it  is 
that  process  through  which  a  commander  exercises  his  authority  in  directing, 
monitoring,  and  integrating  the  effort  of  all  organizations  and  activities 
in  all  BFA.  Within  TRADOC,  the  Combined  Arms  Combat  Development  Activity 
(CACDA)  has  proponency  for  this  functional  area. 

b.  Fire  Support  battlefield  functional  area.  This  is 
the  BFA  which  is  the  major  contributor  of  fire  support  to  maneuver  forces. 
Within  TRADOC,  the  US  Army  Field  Artillery  Center  and  School  has  proponency 
for  this  BFA. 
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HEADQUARTERS 
US  ARMY  TRAINING 
AND  DOCTRINE 
COMMAND 

==!=== 


FORCE  LEVEL 
CONTROL 


INTEGRATING  FUNCTIONAL  AREAS 


COMBINED  ARMS  COMBAT 
DEVELOPMENT  ACTIVITY 


US  ARMY  SIGNAL  CENTER 


BATTLEFIELD  FUNCTIONAL  AREAS 


MANEUVER 


•  COMBINED  ARMS  COMBAT 
DEVELOPMENT  ACTIVITY 

•  US  ARMY  INFANTRY  CENTER 
AND  SCHOOL 

•  US  ARMY  ARMOR  CENTER 
AND  SCHOOL 

•  US  ARMY  AVIATION  CENTER 


•  US  ARMY  ENGINEER  CENTER 


INTELLIGENCE 
AND  ELECTRONIC 
WARFARE 


•  US  ARMY  INTELLIGENCE  CENTER 
AND  SCHOOL 


FIRE  SUPPORT 


•  US  ARMY  -FIELD 
ARTILLERY  CENTER 
AND  SCHOOL 


AIR  DEFENSE 


•  US  ARMY  AIR 
DEFENSE  CENTER 
AND  SCHOOL 


COMBAT  SERVICE 
SUPPORT 


•  US  ARMY  LOGISTICS  CEf^TER 

•  US  ARMY  SOLDIER  SUPPORT 
CENTER 


Figure  8.  TRADOC  organizational  elements  with  key  PDSS 
responsibilities  at  the  BFA  level 
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c_.  Air  Oefense  battlefield  functional  area.  This  is 
the  BFA  responsible  for  reacting  to  and  defeating  enemy  aircraft  and  the 
countermeasures  threat  under  all  environmental  and  tactical  conditions  in 
all  intensities  of  combat.  The  US  Army  Air  Defense  Center  and  School  has 
proponency  for  this  BFA. 

d.  Intelligence  and  Electronic  Warfare  battlefield 
functional  area.  The  intelligence  portion  of  this  BFA  assists  the  commander 
and  his  staff  in  knowing  and  understanding  the  enemy  and  in  seeing  the 
battlefield.  The  electronic  warfare  element  of  the  BFA  is  responsible  for 
attacking  or  defending  systems  that  employ  electromagnetic  energy,  including 
command  and  control,  weapon,  and  acquisition  systems.  The  U.S.  Army 
Intelligence  Center  and  School  is  the  TRADOC  proponent  for  this  BFA. 

e.  Combat  Service  Support  battlefield  functional 

area.  The  two  major  components  of  this  BFA  are  logistics  and  soldier  support. 
The  logistics  portion  of  this  BFA  supports  decision  making  of  each  tactical 
echelon  by  providing  decisive  and  timely  logistic  and/or  technical  expertise 
as  far  forward  as  possible  to  give  the  tactical  commander  a  full  complement 
of  operating  equipment  and  weapons.  The  soldier  support  portion  of  the  BFA 
supports  the  commander  in  seeing  the  battlefield  (friendly  personnel  situa¬ 
tion)  and  in  sustaining  the  forces.  Assistance  and  support  is  also  provided 
to  other  BFA  and  to  the  soldiers  who  man  them.  The  US  Army  Logistics  Center 
is  the  TRADOC  proponent  for  the  logistics  portion  of  the  Combat  Service 
Support  (CSS)  BFA.  The  US  Army  Soldier  Support  Center  is  the  TRADOC  proponent 
for  the  soldier  support  portion  of  the  CSS  BFA. 

£.  Maneuver  battlefield  functional  area.  This  BFA, 
through  its  inherent  subsystems  of  direct  fire  (including  subelements  of 
infantry,  armor,  Army  aviation,  and  air/ground  systems),  engineer,  and  integra¬ 
tion,  provides  the  timely  means  to  generate  and  apply  decisive  combat  power 
on  the  modern  battlefield.  CACDA  has  overall  proponency  for  the  Maneuver  BFA 
and  is  responsible  for  coordinating  and  integrating  the  activities  of  the  US 
Army  Infantry  Center  and  School ,  the  US  Army  Armor  Center  and  School ,  the  US 
Army  Aviation  Center,  and  the  US  Army  Engineer  Center  in  their  respective 
areas  of  responsibility. 

£.  Communications  functional  area.  As  illustrated  in 
Figure  8,  communications  is  not  one  of  the  five  currently  recognized  BFA, 
but  rather  it  is  that  mechanism  through  which  the  commander  directs  and  controls 
all  other  battlefield  functions  in  the  performance  of  his  mission.  Communic¬ 
ations  impacts  on  and  is  impacted  by  all  BFA.  Within  TRADOC,  the  US  Army 
Signal  Center  and  School  is  the  proponent  for  the  communications  functional 
area.  CACDA  has  responsibility  for  coordinating  the  integration  of  actions 
in  the  communications  area  with  those  in  all  other  BFA. 

3.  Regulatory  policy.  The  study  effort  that  was  devoted 
to  regulatory  policy  relevant  to  PDSS  involved  the  review  and  analysis  of 
more  than  seventy-five  Department  of  Defense  (DOD)  Department  of  the  Army, 
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Field  Operating  Agency,  Major  Command,  and  TRADOC  Center  and  School  directives, 
instructions,  regulations,  and  pamphlets.  The  results  of  this  effort  are 
discussed  below. 


£.  Applicable  regulations.  Current  Army  policy 
applicable  to  system  acquisition  and  life  cycle  management  (to  include  post¬ 
deployment  support  of  8AS)  is  contained  in  ARs  1000-1,  70-1,  and  18-1. 

AR  1000-1  contains  basic  policy  for  system  acquisition  and  life  cycle 
management.  The  AR  70-series  provides  additional  details  necessary  to 
implement  AR  1000-1.  These  regulations,  which  are  issued  under  the  propo- 
nency  of  DCSRDA  and  the  control  of  the  Assistant  Secretary  of  the  Army 
(Research,  Development  and  Acquisition),  implement  the  basic  Department  of 
Defense  and  Office  of  Management  and  Budget  procurement  policies.  They  are 
applicable  to  the  acquisition  of  all  BAS  addressed  in  this  study  except 
those  involving  commercial,  general  purpose  automatic  data  processing  systems 
which  must  be  acquired  under  AR  18-1. 

AR  18-1  governs  the  acquisition  of  these  latter  systems,  in  accordance 
with  D0D  directives  and  provisions  of  Public  Law  89-306  (The  Brooks  Bill). 
This  bill  prescribes  special  management  requirements  and  procedures  intended 
to  ensure  the  economic  and  effective  purchase,  lease,  maintenance,  operation, 
and  utilization  of  commercial  ADP  equipment.  The  ACSAC  is  the  Army  Staff 
proponent  for  AR  18-1  which  is  under  the  supervision  of  the  Assistant 
Secretary  of  the  Army  (Installa^ons,  Logistics  and  Financial  Management). 

Thus,  two  separate  and  distinct  sets  of  policy  documents  exist  (AR 
1000-1/AR  70-1  and  AR  18-1)  that  are  applicable  to  the  acquisition  and  life 
cycle  management  of  BAS. 

Ij.  Imputations. 

This  dual  set  of  policy  documents  has  implications  with  respect  to  the 
BAS  addressed  in  this  study.  In  general,  the  USACSC-developed  systems  for 
which  the  Logistics  Center  or  the  Soldier  Support  Center  has  Combat  Developer 
proponency  are  developed  under  provisions  of  AR  18-1  while  other  BAS  are 
developed  under  AR  1000-1  and  the  AR  70-series.  However,  there  are  some 
differences  of  opinion  regarding  the  applicability  and  scope  of  these  reg¬ 
ulations.  Efforts  are  being  made  through  the  recent  revision  of  AR  18-1 
and  the  revisions  currently  being  made  to  ARs  1000-1  and  70-1  to  clarify  the 
applicability  of  each  set  of  regulations  and  to  harmonize  the  requirements 
and  procedures  of  each.  To  the  extent  that  this  effort  is  successful,  it 
should  eliminate  problems  resulting  from  different  interpretation  and  per¬ 
ceived  disparities  in  the  provisions  and  applicability  of  these  policy 
documents  at  the  macro-management  level. 

Also  bearing  directly  on  this  subject  is  the  memorandum  from  the 
Assistant  Secretary  of  the  Army  (RDA),  1  July  1980,  subject:  Standardization 
of  Embedded  Computer  Resources,  and  the  TRADOC  implementing  letter  from  the 


Deputy  Commander,  TRADOC,  30  July  1980.  When  implemented,  the  policy  and 
guidance  contained  in  these  two  documents  will  provide  for  more  standardized 
system  development  and  support  procedures  within  TRADOC. 

c.  Adequacy. 

A  serious  inadequacy  of  Army  regulatory  documents  has  been  that  while 
purporting  to  address  the  entire  life  cycle  of  a  system  from  initiation 
through  development  and  deployment  to  eventual  disposal  upon  obsolescence, 
little  emphasis  is  placed  on  post-deployment  support  in  general  or  on  post¬ 
deployment  software  support  in  particular.  So  great  has  been  the  need  for 
additional  policy  and  guidance  in  this  area  that,  in  the  absence  of  an  Army 
Regulation,  DARCOM  proceeded  to  publish  DARCOM  Regulation  70-16:  Management 
of  Computer  Resources  in  Battlefield  Automated  Systems.  This  DARCOM  regula¬ 
tion  provides,  among  other  things  for  the  documentation  of  PDSS  requirements, 
plans,  and  resource  estimates  early  in  the  acquisition  phase. 

With  respect  to  improving  Army  regulations  which  address  this  area,  the 
new  AR  18-1  does  place  increased  emphasis  on  the  Deployment  and  Operation 
Phase  of  the  system  life  cycle.  However,  changes  are  also  needed  in  ARs  70-1 
and  1000-1  to  provide  for  appropriate  attention  to  PDSS  and  to  preclude  the 
type  of  difficulties  experienced  by  Users  as  a  result  of  system  deficiencies 
and  inadequate  support  planning  to  accomplish  corrective  actions  and  needed 
system  improvements.  Review  of  a  new  draft  chapter  to  be  incorporated  into 
revised  AR  70-1  indicates  this  problem  is  being  addressed  and  that  adequate 
guidance  will  exist  after  publication  of  the  new  AR  70-1.  Following  revision 
to  ARs  1000-1  and  70-1,  DA  Pamphlet  11-25  will  need  to  be  revised  to  corres¬ 
pond  with  the  revised  regulatory  provisions. 

A  TRADOC  regulation  is  also  needed,  comparable  to  DARCOM  Reg.  70-16,  to 
provide  command  policy  with  respect  to  planning  and  performing  PDSS. 

4.  Battlefield  automated  systems  to  be  addressed. 

a_.  Identification  of  systems.  The  portion  of  this 
study  effort  devoted  to  identification  of  the  BAS  for  which  TRADOC  has  Combat 
Developer  PDSS  responsibilities  began  with  a  review  of  systems  identified  in 
the  PDSS  Concept  Plan  for  BAS,  May  1980.  That  study  report  identified  110 
BAS  that  are  deployed  or  projected  for  deployment  during  the  next  several 
years.  Of  these  systems,  6  were  designated  Category  1,  27  Category  2A  or  2B, 
and  58  Category  3.  Nineteen  USACSC-developed  systems,  included  in  the  110, 
were  not  categorized,  but  for  planning  purposes  were  considered  to  be  Category 
2.  Further  analysis  of  these  BAS  during  this  TRADOC  study  resulted  in  some 
modification  to  the  original  listing  in  the  PDSS  Concept  Plan  for  BAS.  These 
modifications  were  made  primarily  to  reflect  new  decisions  to  initiate,  terminate, 
or  change  various  system  design  and  development  programs.  The  numbers  of  BAS 
resulting  from  this  analysis  are  shown  by  BFA  and  by  category  in  Figure  9. 

Details  pertaining  to  each  BAS  are  presented  in  Appendix  C  of  Volume  IV,  Third 
Interim  Technical  Report. 


*  See  pages  6  and  7  for  definitions. 
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FUNCTIONAL  AREA 

OR  BFA 

NUMB 

ER  OF  SYSTEMS 

CATEGORY  1 

CATEGORY  2 

CATEGORY  3 

CSC 

TOTAL 

FORCE  LEVEL  CONTROL 

1 

1 

MANEUVER 

1 

14 

15 

FIRE  SUPPORT 

1 

2 

14 

17 

AIR  DEFENSE 

2 

3 

2 

7 

INTELLIGENCE/EW 

1 

7 

11 

19 

COMBAT  SERVICE  SUPPOf 

T  1 

2 

24 

28 

COMMUNICATIONS 

2 

3 

14 

1 

25 

TOTAL 

8 

21 

57 

25 

no 

Figure  9.  BAS  by  category  and  functional  area 
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t).  Addressal  of  BAS  in  this  report.  While  all  112  BAS 
shown  in  Figure  9  have  been  addressed  to  some  extent  during  this  study,  the 
SAG  guidance  provided  that  the  Study  Team's  effort  should  be  focused  primarily 
on  Category  1  and  2  and  USACSC  systems.  This  guidance  results  from  TRADOC  being 
principally  concerned  with  software  in  these  large  and/or  evolutionary  systems. 
Software  in  Category  3  systems  is  not  expected  to  change  significantly  once 
the  system  is  fielded.  Thus,  primary  effort  during  this  study  was  focused  on 
the  29  Category  1  and  2  systems  and  the  26  USACSC  systems  shown  in  Figure  9. 

(c)  TRADOC  PDSS  responsibilities  and  functional  requirements. 
Analysis  conducted  by  the  Study  Team  during  this  portion  of  the  Phase  I 
effort  revealed  that  TRADOC,  as  the  Army's  principal  Combat  Developer,  has 
a  critical  and  increasing  role  in  the  development  and  life  cycle  management 
and  support  processes  for  battlefield  automated  systems.  There  are  several 
reasons  for  the  increase  in  this  role  but  the  driving  factors  are: 

•  The  growing  trend  toward  embedding  more  doctrine,  tactics,  and 
functional  procedures  in  BAS  software,  thus  necessitating  more 
direct  CD  participation  in  analysis  and  decisions  pertaining  to 
system  changes  that  could  affect  any  of  these  areas, 

•  The  growing  number  of  BAS  being  fielded  which  makes  definition  and 
maintenance  of  functional  interoperability  requirements  more 
complex,  and 

•  The  continually  evolving  nature  of  some  BAS  which  is  an  accepted 
system  development  approach  per  DODI  5000.2,  but  which  has  major 
implications  for  System  and  Combat  Developers,  Users,  and  all  system 
support  activities. 

Fulfillment  of  this  increased  role  in  PDSS  for  BAS  imposes  additional  func¬ 
tional  requirements  on  HQ  TRADOC  and  all  TRADOC  centers  and  schools  involved 
in  supporting  battlefield  systems.  These  PDSS-related  functional  respon¬ 
sibilities  derive  primarily  from  TRADOC' s  basic  responsibilities  as  set  forth 
in  AR  10-41:  Organization  and  Functions,  US  Army  Training  and  Doctrine  Command, 
which  are  expanded  upon  in  other  applicable  Army  and  TRADOC  regulatory  docu¬ 
ments.  Within  the  scope  of  these  TRADOC  regulatory  responsibilities,  the  Study 
Team  identified  specific  CD  PDSS  functional  requirements.  In  structuring  this 
set  of  CD  PDSS  functional  requirements,  the  Study  Team  drew  upon  the  minimum 
set  of  tasks  necessary  for  PDSS  as  shown  in  Figure  10.  Some  of  these  tasks 
are  applicable  only  to  the  MD,  some  only  to  the  CD,  and  some  to  both.  Analysis 
of  this  set  of  minimum  PDSS  tasks,  TRADOC’s  basic  regulatory  responsibilities, 
and  the  role  of  TRADOC  as  the  Army's  principal  Combat  Developer,  provided  a 
basis  for  formulating  a  set  of  PDSS  functional  requirements  generally  common 
to  all  TRADOC  centers  and  schools  involved  with  PDSS  for  BAS.  These  functional 
requirements  are  presented  in  Figure  11,  grouped  into  the  same  six  functional 
task  areas  as  shown  in  Figure  10.  Again,  while  most  of  these  functional  re¬ 
quirements  are  common  to  all  centers  and  schools,  their  magnitude  varies 
among  these  TRADOC  organizations. 
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1 .  Mana< 

lement 

a . 

Development  and  maintenance  of  a  software  sup¬ 
port  plan  responsive  to  user  requirements  as 
determined  by  the  user  representative  (for 
example,  TRADOC  center  or  school) 

b. 

Planning,  acquisition,  and  maintenance  of 
resources 

c. 

Operation  of  the  PDSS  centers/support  facilities 

d. 

Configuration  management  of  the  software 
system. 

2.  Anal 

nil 

a. 

Analysis  of  a  system  to  determine  the  nature  of 
the  problem  —  whether  hardware,  software  or 
both 

b. 

Analysis  of  software  problem  reports 

c. 

Analysis  of  proposed  system  changes  to  deter¬ 
mine  technical,  operational,  resource,  and 
schedule  impacts 

d. 

Analysis  of  support  software  changes  due  to 
hardware  variations 

e. 

Determination  of  the  possible  impact  of  soft¬ 
ware  changes  on  hardware/software 

f. 

Analysis  of  system  changes  due  to  interopera¬ 
bility  requirements. 

g. 

Analysis  of  conceptual  changes  to  fielded 
systems,  such  as  doctrine,  tactics,  operating 
procedures,  command  and  control,  organizational 
concepts,  training,  and  logistics. 

3.  Modification 

a. 

Development  of  system/software  change 
requirements 

Figure  10.  Minimum  set  of  tasks  necessary  for  PDSS* 
(Continued  on  next  page) 

*  As  defined  in  the  PUSS  Concept  Plan  for  BAS,  May  1980 
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b. 

Development,  design,  implementation,  and 
documentation  of  all  software  modifications 

c. 

Maintenance  of  documentation  necessary  to 
support  existing  software  and  development 
systems 

d. 

Distribution  of  changes  in  accordance  with 
the  Configuration  Management  Plan 

e. 

Compliance  with  approved  desiyr  standards 

f. 

Compliance  with  approved  programming 
standards 

g- 

Compliance  with  approved  documentation 
standards 

4. 

Test 

a. 

Verification  and  validation  of  software 
and  system  changes 

b. 

Testing  and  evaluation  of  the  impact  of 
changes  on  the  operational  function 

c. 

User  acceptance  testing,  including  evalua¬ 
tion  of  operational  suitability  and  oper¬ 
ational  effectiveness. 

5. 

Field  Support 

a. 

Provision  of  field  support,  including 
development  and  guidance  to  the  field  on 
operation  and  employment  of  the  systems 

b. 

Maintenance  of  communication  and  procedures 
between  the  field  and  support  activity. 

6. 

Other 

a. 

Development  of  system  test  and  analysis 
software/hardware 

b. 

Development  and  maintenance  of  simulations 
and  emulations,  where  required 

Figure  10.  (continued) 
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c.  Development  and  conduct  of  the  training 
necessary  to  introduce  new  software  versions 
and  maintain  old  systems 

d.  Development  and  distribution  of  procedural, 
operational,  training,  and  maintenance 
documentation  and  special  operating  instruc¬ 
tions. 


Figure  10.  (concluded) 


TASK  AREA  TRADOC  RESPONSIBILITY  FUNCTIONS 


COMMAND  AND  CONTROL,  ORGANIZA¬ 
TIONAL  CONCEPTS,  TECHNOLOGY, 
THREAT). 


TASK  AREA _ TRADOC  RESPONSIBILITY _ FUNCTIONS _ 

ANALYSIS  4.  ANALYZE  FUNCTIONAL  IMPACT  OF  1.  IDENTIFY  OPERATIONAL  IMPACT. 

(CONTINUED)  PROPOSED  SYSTEM  CHANGES.  2.  IDENTIFY  USER-RESOURCE  REQUIREMENT  IMPACT. 

3.  IDENTIFY  TRAINING  IMPACT. 


DEVELOP  AND  PROVIDE  GUIDANCE  ON  DOCTRINAL/ 

TACTICAL  ASPECTS  OF  SYSTEM  EMPLOYMENT. 

COORDINATE  WITH  MD  ON  THE  SCHEDULE  AND  METHODOLOGY 
FOR  DISTRIBUTION  OF  SYSTEM  SOFTWARE  CHANGE  PACKAGE 
TO  THE  FIELD. 
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(2)  Phase  II.  As  discussed  in  the  methodology.  Paragraph  3.e.,  this 
phase  of  the  study  was  conducted  to  develop  alternative  TRADOC  functional  and 
management  PDSS  models  or  systems  for  fulfilling  the  Combat  Developer's 
responsibilities  for  planning  and  providing  PDSS  to  BAS.  In  pursuit  of  this 
objective,  the  Baseline  and  two  alternative  systems  were  defined  for  TRADOC 
consideration.  These  alternatives  were  called  the  Theoretical  System,  re¬ 
presenting  a  potentially  achievable  ideal,  and  the  Hybrid  System,  derived 
from  a  comparative  analysis  of  the  Theoretical  and  Baseline  Systems.  A  brief 
discussion  of  each  of  these  alternatives  and  the  results  of  the  TRADOC  SAG 
review  are  presented  in  the  paragraphs  that  follow: 

(a)  The  Baseline  System. 

JL  System  descriptions.  The  Baseline  System  description 
was  developed  based  primarily  on  information  obtained  during  Phase  I,  supple¬ 
mented  by  additional  research  and  input  from  SAG  members  during  Phase  II. 

This  system  was  described  within  the  context  of  the  BFA  concept,  and  identified 
organizational  elements  involved  with  PDSS  to  tne  branch  or  separate  office 
level  within  each  TRADOC  functional  center  and  school  that  currently  has  CD 
PDSS  responsibilities  for  one  or  more  BAS.  These  centers  and  schools  involved 
in  the  Baseline  System  and  the  number  of  BAS  for  which  they  have  proponency 
are  shown  in  Figure  12. 

2_.  Baseline  analysis.  Analysis  of  this  Baseline  revealed 
that,  to  the  extent  that  PDSS  was  being  accomplished  within  TRADOC,  it  was 
being  performed  as  an  integral  part  of  the  system  development  and  life  cycle 
management  process  under  the  combat  developments  mission.  However,  this 
analysis  also  revealed  that  resources  available  in  the  Baseline  System  were 
not  adequate  to  permit  TRADOC  organizations  to  accomplish  those  CD  PDSS 
functions  for  which  they  are  responsible.  Based  on  this  analysis,  the 
Study  Team  developed  estimates  of  additional  personnel  resources  that  need  to 
be  added  to  the  Baseline  to  provide  a  minimally  acceptable  capability  to 
perform  essential  PDSS  functions.  These  additional  resources  are  needed  to 
provide  a  capability  to  accomplish  important  CD  PDSS  functions  not  presently 
being  performed  for  BAS  already  fielded,  and  to  provide  PDSS  for  additional 
BAS  projected  for  deployment  through  1987.  Chapter  2  and  Appendix  D  of 
Volume  III,  Second  Interim  Technical  Report,  contain  this  Baseline  System 
description. 


(b)  The  Theoretical  System.  The  Study  Team's  effort  focused 
next  on  design  of  a  TRADOC  Theoretical  PDSS  System  which  would,  if  implemented, 
provide  a  capability  to  accomplish  all  currently  identified  CD  PDSS  functions 
for  all  BAS  projected  for  deployment  through  1987.  This  system  was  also 
designed  within  the  context  of  the  BFA  concept  and  described  to  the  branch 
or  separate  office  level  of  detail. 

1_.  Design  guidelines.  The  principal  guidelines  and  other 
considerations  that  were  followed  in  designing  this  Theoretical  PDSS  System 
are  suimarized  below: 
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ORDNANCE  CENTER 
0/0/2 


NOTE:  NUMBER  OF  CATEGORY  1,  2,  AND  3  BAS 
ORDNANCE  CENTER  F0R  WHICH  EACH  ORGANIZATION  SHOWN 

0/0/2  ABOVE  IS  PROPONENT  is  SHOWN  IN 

EACH  RECTANGLE,  E.G.,  1/3/0  MEANS 

-  1  CATEGORY  1,  3  CATEGORY  2 

AND  NO  CATEGORY  3  BAS. 


Figure  12.  TRADOC  orgcni zations  by  BFA  which  require  a  POSS  capability 


P 
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a_.  Focus  on  the  future.  The  focus  of  the  study  team 
in  designing  this  Theoretical  System  was  on  the  future.  This  approach  was 
adopted  to  ensure  that  appropriate  consideration  would  be  devoted  to  known 
future  POSS  requirements  and  to  allow  adequate  time  for  TRADOC  to  integrate 
its  system  implementation  effort  with  the  Army's  Planning,  Programming,  and 
Budgeting  System. 


b^.  Applicability  of  current  policy. 

•  The  Theoretical  System  is  to  be  bounded  by  current  Army  regulations 
and  the  PDSS  Concept  Plan  for  BAS. 

•  The  Theoretical  System  is  to  be  in  consonance  with  TRADOC  Regs. 

10-5  and  10-41,  the  BFA  concept,  and  the  Command,  Control,  and 
Subordinate  Systems  (CCS^)  Concept. 

c.  Resources.  The  System  will  not  be  constrained  by 

resources. 

d.  Addressal  of  requirements.  The  System  must  provide 
for  an  adequate  PDSS  capability  at  each  TRADOC  center  and  school  determined, 
during  Phase  I  and  during  definition  of  the  Baseline  System,  to  have  PDSS 
responsibilities  for  one  or  more  BAS. 

2.  Definition  of  the  required  capability.  Having  identified 
during  Phase  I  what  PDSS  requirements  must  be  satisfied,  the  Study  Team  pro¬ 
ceeded  to  determine  what  capability  is  needed  to  meet  the  requirements. 
Capability  was  addressed  in  terms  of  organizational  elements  and  their  re¬ 
sources.  Resources  were  matched  to  workload  according  to  the  TRADOC  11-series 
of  regulations  and  pamphlets  to  the  extent  possible.  This  effort  focused  on 
tailoring  each  system  component  or  element  to  the  needs  of  the  local  parent 
center  or  school  organization.  Personnel,  major  equipment,  and  physical 
facility  requirements  were  addressed. 

2-  Results  of  the  design  effort.  The  result  of  this  effort 
was  a  system,  which  would,  if  implemented,  provide  the  required  PDSS  capability 
at  HQ  TRADOC  and  at  each  TRADOC  center  and  school  shown  in  Figure  12.  The 
capability  was  tailored  to  the  needs  of  each  center  and  school  but,  in  all 
cases,  it  was  designed  to  become  an  integral  part  of,  and  function  under,  the 
Directorate  of  Combat  Developments  or  the  Management  Information  Systems 
Directorate  at  each  center  and  school.  This  design  would  be  consistent  with 
current  operational  concepts  and  would  minimize  changes  to  the  existing  organ¬ 
izational  structure  and  operating  procedures.  Resources  needed  to  implement 
the  system  were  projected  through  1987,  in  accordance  with  current  PDSS  re¬ 
quirements  and  projected  requirements  associated  with  planned  deployment  of 
new  BAS  or  the  further  extension  of  existing  BAS.  This  Theoretical  PDSS  System 
is  discussed  in  detail  in  Chapter  3  and  Appendix  E,  Volume  III,  Second  Interim 
Technical  Report. 
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(c)  The  Hybrid  System 

1_.  Basis  for  the  system  design.  As  indicated  in  the 
discussion  of  the  methodology  in  Paragraph  3.e.,  a  comparative  analysis  was 
made  of  the  Baseline  and  Theoretical  Systems  to  evaluate  these  systems  and 
provide  a  basis  for  designing  another  alternative  called  the  Hybrid  System. 

2_.  Results  of  the  comparison  and  design  effort.  This 
comparison  revealed  that  the  Theoretical  System  offered  advantages  over  the 
Baseline  in  virtually  all  areas  of  comparison  except  in  resources  required. 

Thus,  while  the  resultant  Hybrid  System  incorporates  desirable  features  of 
both  the  Baseline  and  Theoretical  Systems,  it  is  heavily  oriented  toward  the 
Theoretical  System.  It  would  provide  for  the  establishment  of  a  capability 
at  each  TRADOC  center  and  school  shown  in  Figure  12.  The  organizational 
alignment  and  relationships  of  the  elements  of  this  Hybrid  System  were 
essentially  the  same  as  those  discussed  in  connection  with  the  Theoretical 
System  in  Paragraph  (b)  above.  As  in  the  case  of  the  Theoretical  System, 
no  specific  resource  constraints  were  imposed  on  design  of  the  Hybrid  System. 
However,  a  conscientious  effort  was  made  to  reduce  resource  requirements  through 
consolidation  of  responsibilities  and  sharing  of  capabilities  without  severely 
degrading  the  capability  of  the  resulting  system.  The  result  was  a  Hybrid 
System  that  would,  if  implemented,  provide  a  capability  significantly  greater 
than  the  Baseline  and  comparable  to  that  of  the  Theoretical  System  in  most 
functional  areas,  with  some  reduction  in  resources.  Details  of  the  Hybrid 
System  are  presented  in  Chapter  5  and  Appendix  F  of  Volume  III,  Second 
Interim  Technical  Report. 

(d)  Comparison  of  resource  requirements.  A  comparison  of  the 
personnel  estimated  to  be  required  to  enhance  the  Baseline  System  as  discussed 
in  Paragraph  (a)  above,  and  to  fully  implement  the  Theoretical  and  Hybrid 
Systems  in  1987  is  shown  in  Figure  13.  Further  details  on  resource  require¬ 
ments  associated  with  each  system  are  presented  in  Chapters  2,  3,  and  5, 

Volume  III,  Second  Interim  Technical  Report. 

(3)  Phase  III.  The  Study  Team’s  efforts  during  Phase  III  were  devoted 
to  the  development  of  a  description  of  the  TRADOC  Preferred  or  "Objective" 

PDSS  System  and  the  preparation  of  a  plan  for  transitioning  from  the  present 
situation  to  implementation  of  the  Objective  System.  Each  of  these  efforts 
are  discussed  below. 

(a)  The  TRADOC  Objective  PDSS  System.  The  description  of  the 
TRADOC  Objective  PDSS  System  was  developed  by  the  Study  Team  based  on  guide- 
ance  provided  by  the  SAG,  following  its  review  of  the  TRADOC  PDSS  Baseline, 
Theoretical,  and  Hybrid  System  alternatives  which  were  presented  at  the 
Phase  Ii  SAG  Meeting,  17-18  December  1980.  This  Objective  PDSS  System  in¬ 
corporates  desirable  features  and  capabilities  of  the  organizational  struc¬ 
ture  and  operating  procedures  of  the  current  Baseline  as  well  as  the  proposed 
Theoretical  and  Hybrid  System  alternatives  developed  during  Phase  II.  The 
result  is  an  Objective  System,  tailored  to  the  PDSS-capabi 1 i ty  requirements 


NUMBER  OF 
PERSONNEL 


gure  13.  Comparison  of  estimated  personnel  requirements 
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of  HQ  TRADOC  and  each  integrating  and  functional  center  with  significant  CD 
responsibilities  for  battlefield  automated  systems.  The  design  of  this 
Objective  PDSS  System  provides  an  appropriate  degree  of  uniformity  and 
comnonality  throughout  the  system  while  recognizing  the  need  for  certain 
differences  among  system  components  because  of  variations  in  both  current 
capability  and  current  and  future  requirements  for  PDSS  at  the  various 
centers  and  schools.  The  full  implementation  and  effective  management  of 
this  Objective  PDSS  System  would  provide  HQ  TRADOC  and  subordinate  commands 
an  adequate  capability  to  fulfill  their  roles  and  responsibilities  in 
planning  and  providing  PDSS  for  BAS  currently  projected  for  deployment 
through  1987. 


(b)  Principal  factors  influencing  system  design.  The  principal 
factors  influencing  system  design  were:  ~ 

]_.  Assumptions.  The  assumptions  considered  are  those 
stated  in  Paragraph  3.d. 

2_.  Design  guidelines. 

a.  Relationship  of  PDSS  to  TRADOC  mission  and  func¬ 
tions.  Within  TRADOC,  PDSS  is  to  be  performed  as  an  integral  part  of  the 
system  development  and  life  cycle  management  process  under  the  combat  develop¬ 
ments  mission. 


b.  Relationship  of  PDSS  to  operational  concepts.  The 
system  to  be  established  for  performing  PDSS  is  to  be  in  consonance  with: 

•  TRADOC' s  operational  and  management  concept  of  centralized  manage¬ 
ment  and  decentralized  control  and  operations,  as  described  in  AR 
10-41  and  TRADOC  Regs.  10-5  and  10-41 

•  The  Battlefield  Functional  Area  (BFA)  Concept  discussed  in 
Paragraph  3. a 

9 

•  The  Command,  Control,  and  Subordinate  Systems  (CCS  )  concept 
currently  promulgated  within  TRADOC 

•  The  PDSS  Concept  Plan  for  BAS,  May  1980. 

c.  Relationships  among  centers  and  schools.  Relation¬ 
ships  among  PDSS  organizational  elements  at  the  various  centers  and  schools 
will  be  governed  by  the  existing  integrating  center-associated  center  and 
school  concept  discussed  in  TRADOC  Reg.  10-41.  PDSS  elements  of  key  centers 
and  schools  should  be  interconnected  by  appropriate  means  to  facilitate  the 
coordination  and  interaction  that  must  occur  among  these  centers  and  schools 
in  managing  the  major  command  and  control  BAS  under  the  CCS^  concept. 
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d.  Organizational  structuring.  Within  the  common 
design  guidelines  set  forth  in  this  chapter,  the  PDSS  system  elements  at 
each  center  and  school  may  be  individually  tailored  to  best  accomplish  local 
POSS  requirements.  The  system  should  capitalize  on  existing  analytical  and 
software  capabilities  to  the  extent  possible.  The  extent  to  which  a 
center  and  school's  POSS  capability  is  integrated  into  the  existing  or¬ 
ganizational  structure  as  opposed  to  being  a  separately  identified 
organizational  element  may  vary  based  upon: 

•  Current  capabilities  to  fulfill  PDSS  responsibilities 

•  The  number,  nature,  and  life  cycle  stage  of  BAS  for  which  the 
center  and  school  is  responsible 

•  Relationship  to  an  associated  MD-managed  PDSS  center 

•  Desires  and  objectives  of  each  center  and  school  commander. 

e^.  System  implementation.  This  PDSS  system  represents 
an  objective  to  be  achieved  by  1987  through  the  accomplishment  of  implemen¬ 
tation  actions  integrated  with  the  Army's  Planning,  Programming,  and  Budgeting 
System  (PPBS)  cycle.  Resource  requirements  are  identified  as  needed  beginning 
in  1981. 


(c)  System  Models 

1_.  Generalized  Software  Support  Model  for  PDSS.  The  Task 
Force  that  prepared  the  PDSS  Concept  Plan  for  BAS  developed  a  generalized 
software  support  model  for  PDSS.  This  model,  which  illustrates  the  general 
roles  of  both  the  CD  and  MD  in  the  PDSS  process  and  their  relationships  with 
system  Users,  is  illustrated  in  this  report  as  Figure  14.  This  model  combines 
aspects  of  organizational  structure,  physical  location,  and  information  flow. 
The  model  was  designed  to  provide  for  a  systematic  flow  of  post-deployment 
software  problems  and  solutions  between  the  User  and  appropriate  CD  and  MD 
organizations.  As  indicated,  the  focal  point  for  MD  PDSS  activity  is  the  PDSS 
center.  The  PDSS  Concept  Plan  for  BAS  provides  for  establishing  11  of  these 
centers  as  discussed  in  Paragraph  3. a.  As  shown  in  Figure  14,  the  CD  counter¬ 
part  to,  and  principal  point  of  interface  with,  the  MD-managed  PDSS  center  is 
to  be  the  CDSF.  The  CDSF,  which  represents  the  focal  point  for  CD  PDSS 
activity,  is  to  operate  in  response  to  requirements  of  the  CDSM  who  has  CD 
PDSS  responsibility  for  the  system  or  systems  being  addressed.  The  CDSM,  in 
turn,  represents  the  CD  in  interactions  with  the  Materiel  Manager  under 
whose  supervision  the  PDSS  center  functions.  It  should  be  noted  that  the 
CDSF  should  be  construed  more  as  a  physical  facility  than  an  organizational 
entity.  Like  a  command  post,  the  CDSF  is  essentially  a  place  where  equipment 
and  personnel  from  various  organizational  entities  are  collocated  and 
structured  to  most  effectively  perform  certain  PDSS  functions,  when  or  as 
required.  The  CDSF,  with  respect  to  both  the  physical  facility  itself  and 
the  staff  entities  located  within  it,  may  be  either  permanent  or  temporary. 


GENERALIZED  SOFTWARE  SUPPORT  MODEL  FOR  PDSS* 


Based  on  illustration  in  the  PDSS  Concept  Plan  for 
BAS,  May  1980. 


Figure  14.  Generalized  Software  Support  Model  for  PDSS 
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2_.  Generalized  Combat  Developer  PDSS  Models.  Considering 
the  structure  and  procedural  concept  of  the  Generalized  Support  Model  for 
PDSS,  and  the  Objective  PDSS  System  design  guidelines  discussed  above,  the 
Study  Team  developed  two  models  for  the  functional  and  management  structure 
of  the  CDSF.  Two  generalized  models  (representing  opposite  points  on  a 
spectrum)  were  needed  to  accommodate  the  differences  in  current  organizational 
structure,  capabilities,  and  requirements  among  TRADOC  centers  and  schools. 

The  overall  TRADOC  Objective  PDSS  System  design  is  based  on  one  or  the  other 
or  some  intermediate  variation  of  these  generalized  models  being  implemented 
at  each  center  and  school  that  has  a  need  for  a  PDSS  capability.  The  two 
models  are  described  below: 

a_.  CD  PDSS  Generalized  Model  1.  This  model,  which  is 
illustrated  in  Figure  15,  is  based  on  the  existence/establishment  of  a  per¬ 
manent  organizational  entity  dedicated  to  PDSS  functions  and  staffed  by  an 
element  of  the  Directorate  of  Combat  Developments  or  the  Management  Inform¬ 
ation  Systems  Directorate  at  centers  and  schools  where  this  latter  organiz¬ 
ational  element  has  PDSS  responsibility.  This  PDSS  entity  is  taken,  in  this 
model,  to  be  located,  together  with  personnel  and  equipment,  in  a  permanent 
facility  identified  as  a  CDSF.  This  CDSF  corresponds  with  the  CDSF  box 
shown  in  Figure  14.  Other  directorates  and  staff  organizations  of  the 
center  and  school  would  support  PDSS  functions  within  their  respective 
functional  areas  of  responsibil ity,  on  an  "as  required"  basis.  The  figure 
shows  those  elements  constituting  the  permanent  staffing  of  the  CDSF  as  well 
as  the  principal  organizational  elements  participating  in  PDSS  func¬ 
tions  "as  required".  The  permanent  CDSF  staff  element(s)  function  under  the 
staff  supervision  of  the  Director  of  Combat  Developments  or  a  designated 
division  or  separate  office  chief  of  this  directorate.  Close  staff  coordina¬ 
tion  is  maintained  with  the  appropriate  CDSM  and  with  the  TSM,  if  a  TSM  exists, 
and  with  other  staff  elements  supporting  PDSS  functions.  Both  the  CDSM  and 
the  Chief  of  the  permanent  CDSF  Staff  Element  interface  with  MD  counterparts 
as  illustrated  in  Figure  15.  The  CDSM  is  the  principal  CD  representative  on 
PDSS  matters  involving  the  BAS(s)  for  which  he  is  responsible.  As  indicated 
in  Figure  15,  CD  organizations  in  any  given  CDSF  may  have  to  interface  with 
more  than  one  MD  PDSS  center  since  MD  responsibility  for  the  BAS(s)  supported 
within  a  single  CDSF  may  be  assigned  to  more  than  one  PDSS  center,  in 
accordance  with  the  PDSS  Concept  Plan  for  BAS,  May  1980. 

b^.  CD  PDSS  Generalized  Model  2.  This  model,  which  is 
illustrated  in  Figure  16,  differs  from  Model  1  in  that,  with  the  exception  of 
a  designated  PDSS  focal  point,  no  distinct  PDSS  organizational  entity  exists 
on  a  permanent  basis  and  there  is  no  permanent  CDSF.  Model  2  is  based  on  the 
concept  of  PDSS  functions  being  performed  by  existing  organizational  elements 
(augmented  as  necessary  consistent  with  the  additional  workload  resulting  from 
PDSS).  This  model  allows  for  the  establishment  of  a  CDSF  on  an  ad  hoc  basis 
as  required,  with  staffing  being  drawn  temporarily  from  the  Directorate  of 
Combat  Developments  and  other  existing  organizational  elements  that  have  PDSS 
responsibilities.  When  such  a  CDSF  is  formed,  primary  responsibility  for 
direction  and  control  of  the  total  operation  rests  with  the  principal  Combat 
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Figure  15.  CD  PDSS  Generalized  Model  1 


A 


40 


Developments  Directorate  element  involved.  Other  internal  CD  staff  super¬ 
vision  and  coordination,  and  CD-MD  interface  procedures  and  responsibilities 
envisioned  under  Model  2  are  essentially  the  same  as  described  for  Model  1. 

(d)  Objective  System  Overview.  Following  the  assumptions,  design 
guidelines,  generalized  model  alternatives,  and  other  considerations  discussed 
above,  the  Study  Team  designed  and  developed  the  description  of  the  TRADOC 
Objective  PDSS  System.  This  system  is  illustrated  in  Figure  17,  structured 
within  the  context  of  the  BFA  concept.  This  Objective  System  provides  for: 

•  A  PDSS  Staff  Element  at  Headquarters,  TRADOC  to  provide  a  focal 
point  for  PDSS  at  the  major  command  level  and,  in  conjunction 
with  the  HQ  TRADOC  CD  "hardware  directorates,"  to  coordinate  and 
exercise  staff  supervision  over  PDSS  matters  within  TRADOC 

•  PDSS  Staff  Elements  at  CACDA  to  provide  a  capability  to  fulfill 
assigned  responsibilities  as  the  TRADOC  PDSS  proponent  aRd 
principal  integrating  center  and  as  proponent  of  the  CCS^  concept 

•  A  PDSS  capability  at  the  seven  major  TRADOC  doctrinal  centers  that 
have  proponency  for  functional  area  components  of  the  BFA  concept 

•  A  CDSM  for  each  BAS  that  has  reached  Milestone  II  in  the  system 
development  cycle  (or  a  comparable  point  for  systems  being  develop¬ 
ed  under  other  (e.g.,  evolutionary)  concepts)  (A  CDSM  may  be  re¬ 
sponsible  for  more  than  one  BAS.) 

•  A  capability  to  establish  and  maintain  an  interface  with  geographic¬ 
ally  separated  MD  PDSS  centers  with  which  the  CD  must  interact 
regularly  in  planning  and  providing  PDSS  for  BAS  for  which  the  MD 
and  CD  each  have  major  responsibilities  in  their  respective  func¬ 
tional  areas.  The  way  in  which  interaction  is  accomplished, 
whether  by  permanent  liaison,  TDY,  or  other  means,  is  the  prerogative 
of  each  center  and  school,  in  coordination  with  its  MD  counterpart(s) . 

It  is  emphasized  that  the  composition  of  this  total  system  as  well  as  each  of 
its  elements  has  been  tailored  to  satisfy  TRADOC's  functional  PDSS  requirements. 
Each  component  and  subordinate  element  of  the  system  is  discussed  in  detail  in 
Paragraph  2-5,  Volume  IV,  Third  Interim  Technical  Report. 


(e)  Concept  of  operations.  The  concept  of  operations  associ¬ 
ated  with  this  Objective  PDSS  System  is  in  full  accordance  with  current  De¬ 
partment  of  the  Army  and  TRADOC  operating  policies  and  procedures.  Principal 
elements  of  this  concept  are  discussed  below. 


1_.  HQ  TRADOC.  The  Commanding  General,  TRADOC,  through 
the  Deputy  Chief  of  Staff  for  Combat  Developments  (DCSCD),  establishes  oper¬ 
ating  policy,  determines  priorities,  allocates  and  manages  resources,  and 
directs  all  elements  of  this  Objective  PDSS  System  in  the  accomplishment  of 
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Figure  17.  Overview  of  the  Objective  PDSS  System 
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the  overall  mission  and  principal  functional  responsibilities.  Within  DCSCD, 
the  Telecommunications,  Command  and  Control,  and  Computer  Systems  (TC4S) 
Directorate,  the  Systems  Management  Directorate,  and  each  of  the  "hardware 
directorates" ,  e.g..  Firepower  Systems,  Maneuver  Systems,  etc.,  have  PDSS 
responsibilities. 


e.  DCSCD  TC4S  Directorate.  The  Director,  TC4S,  exercises 
staff  supervision  over  the  total  operation  of  the  system.  Within  this  Director¬ 
ate,  the  Battlefield  Systems  Integration  Branch  provides  the  focal  point  for 
coordinating  TRADOC  PDSS  activity  and  requirements.  This  branch  is  responsible 
for  receiving  and  acting  or  coordinating  action  on  directives  or  requirements 
from  Headquarters,  Department  of  the  Army  (HQDA),  or  the  Commanding  General 
and  other  appropriate  officials  of  Headquarters,  TRADOC,  and  on  requests  from 
User  commands.  In  conjunction  with  the  DCSCD  hardware  directorate(s)  and  the 
CACDA  PDSS  Staff  Element  (discussed  below),  this  branch  analyzes  and  translates 
these  requirements  into  instructions  for  issuance  by  Headquarters  TRADOC  to 
subordinate  commands.  Subsequently,  the  branch  exercises  staff  supervision 
and  acts  in  coordination  with  other  staff  elements  of  DCSCD  on  the  products 
of  subordinate  elements  of  the  system. 

1).  DCSCD  hardware  directorates.  The  DCSCD  hardwire 
directorates  exercise  staff  supervision  for  total  systems  management  of 
systems  within  their  respective  functional  areas. 

£.  DCSCD  Systems  Management  Directorate.  The  Systems 
Management  Directorate  exercises  primary  staff  responsibility  for  management 
of  the  TRADOC  Materiel  Total  System  Management  Concept  and  the  TSM  Program. 

2.  CACDA.  CACDA  is  responsible  in  this  Objective  System 
as  the  TRADOC  PDSS  Proponent.  Responsibilities  associated  with  this  role 
include  working,  in  conjunction  with  the  PDSS  staff  at  Headquarters  TRADOC, 
to  address  major  PDSS  functional  and  management  matters,  and  coordinating 
and  integrating,  as  appropriate,  PDSS  requirements  and  activity  of  the 
TRADOC  centers  and  schools. 

3_.  BFA-level  operations.  As  noted  in  the  System  Overview, 
this  Objective  System  provides  for  a  PDSS  capability  within  each  of  the  seven 
functional  areas  recognized  in  the  BFA  concept.  This  PDSS  capability  is 
established  and  will  operate  as  an  integral  part  of  the  combat  developments 
or  management  information  systems  organization  of  each  parent  center  and 
school.  This  PDSS  capability  provides  a  focal  point  for  all  substantive  PDSS 
activity  within  each  of  the  seven  functional  areas  of  the  BFA  concept  and 
provides  the  primary  interface  on  PDSS  matters  at  the  BFA  level  with  organ¬ 
izations  external  to  TRADOC.  Each  of  the  centers  and  schools  that  is  to  have 
a  PDSS  capability  will  be  responsible  for  planning,  directing,  coordinating, 
and  performing  all  CD  PDSS  functions  for  the  BAS  within  their  respective 
functional  areas.  This  includes  maintaining  contact  with  Systems  Users  on 
functional/operational  matters  and  with  MD  PDSS  centers  on  all  aspects  of 
POSS  for  the  BAS  with  which  they  are  concerned.  The  CD  POSS  LNOs  included  in 
this  Objective  System  are  extensions  of  their  respective  CDSF.  They  facilitate 
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CD-MD  interaction  on  PDSS  for  the  BAS  with  which  they  are  concerned  and  provide 
the  principal  User-representation  at  the  MD  PDSS  center  where  they  are 
located.  Those  centers  and  schools  choosing  not  to  establish  permanent 
liaison  representation  at  geographically  separated  MD  PDSS  centers  with 
which  they  must  interact,  must  accomplish  this  functional  requirement  by 
other  means  consistent  with  the  concpet  and  objectives  of  this  TRADOC 
Objective  PDSS  System.  A  detailed  description  of  each  of  the  seven  BFA-level 
Objective  PDSS  System  components  is  given  in  Paragraph  2-5,  Volume  IV. 

4.  Principal  interfaces.  To  properly  fulfill  its  CD  PDSS 
functions,  HQ  TRADOC  and  each  center  and  school  involved  with  the  Objective 
PDSS  System,  must  interact  with  both  Users  and  Materiel/System  Developers  on 
a  continuing  basis.  The  CD  liaison  elements  or  points  of  contact  to  be 
established  as  part  of  this  Objective  PDSS  System  will  facilitate  this  interface. 

A  summary  of  the  principal  CD-MD-User  interfaces  that  are  seen  to  be  required 
following  implementation  of  the  PDSS  Concept  Plan  for  BAS,  are  shown  in  Figure 
18. 


(f)  Resource  requirements.  The  detailed  description  of  tne 

Objective  PDSS  System  contained  in  Volume  IV,  Third  Interim  Technical  Report, 

includes  a  discussion  of  estimates  of  resource  requirements  necessary  to 

implement  the  system.  While  the  estimates  of  resource  requirements  included 
in  that  discussion  must  be  developed  further  and  refined  during  detailed  im¬ 
plementation  planning  at  the  center  and  school  level,  a  summary  of  the  total 
personnel  estimated  to  be  needed  is  provided  in  Figure  19.  The  data  shown 
are  subject  to  change  during  the  detailed  planning  referred  to  above,  but  are 

presented  here  to  provide  an  indication  of  the  magnitude  of  the  resources 

needed  for  this  critical  functional  area. 

(g)  Implementation  planning. 

1_.  Structure  of  the  plan.  A  proposed  implementation  plan, 
to  be  staffed,  approved,  and  issued  by  HQ  TRADOC,  has  been  prepared  and  is 
included  as  Appendix  0  of  Volume  IV,  Third  Interim  Technical  Report.  The 
proposed  implementation  plan  covers  those  principal  actions  or  events  that 
need  to  be  accomplished  during  the  initial  period  of  this  TRADOC  implemen¬ 
tation  effort,  from  March  1981  through  March  1982.  If  this  schedule  is 
maintained,  other  actions  originating  from  these  initial  actions  will  then 
continue  on  for  several  years  before  full  implementation  is  achieved  in  1987. 
During  this  period  and  beyond,  a  number  of  actions  associated  with  the  TRADOC 
Resources  Management  System  (TRADOC  Pam.  11-11)  and  the  Priorities  and  Tasking 
Control  Process  (TRADOC  Reg.  11-2)  must  be  accomplished  on  a  recurring  basis. 

2.  Critical  aspects  of  the  schedule.  In  the  interest  of 
proceeding  with  implementation  expeditiously,  a  very  compressed  schedule  has 
been  proposed  for  the  execution  of  this  plan.  For  example,  it  provides  for 
the  accomplishment  of  special  actions  directed  toward  the  inclusion  of  criti¬ 
cal  PDSS  resource  requirements  in  the  FY  83  TRADOC  Command  Budget  Estimate 
(CBE).  If  these  actions  are  not  taken,  a  delay  of  one  year  may  be  experienced 
in  getting  PDSS  requirements  into  the  programming  and  budgeting  process.  To 
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NUMBER  ESTIMATE  OF  PERSONNEL  REQUIREMENTS 

OF  - 

PERSONNEL 


FISCAL  YEAR  81  82  83  84  85  86  87 


LEGEND: 


NUMBER  OF  AUTHORIZED  PERSONNEL 


NUMBER  OF  ADDITIONAL  PERSONNEL  REQUIRED 


Figure  19.  Estimated  TRADOC  PDSS  personnel  requirements  by  fiscal  year 


46 


meet  the  schedule  that  is  proposed,  some  actions  must  be  initiated  immediately 
following  receipt  of  this  final  report.  Some  of  these  early  actions  would 
have  to  precede  the  finalization  and  issuance  of  the  proposed  implementation 
plan  since  the  proposed  schedule  provides  for  the  plan  to  be  revised  following 
formal  TRADOC  review  (expected  to  be  in  late  March  or  early  April)  and  staffed, 
published,  and  distributed  in  late  August  or  early  September  1981. 

4.  CONCLUSIONS.  The  following  conclusions  are  reached  based  on  results  of 
the  research  and  analysis  conducted  throughout  Phases  I,  II,  and  III  of  this 
study. 


a.  The  importance  of  establishing  a  systematic  approach  to  planning  for 
and  providing  PDSS  to  BAS  on  an  Army-wide  basis  is  increasing  rapidly  as 
growing  numbers  of  sophisticated  systems  continue  to  be  fielded. 

b.  To  date  only  a  few  BAS  have  involved  TRADOC  in  serious  participation 
in  PDSS  activities.  In  the  next  six  years,  however,  approximately  26  BAS 
requiring  significant  TRADOC  participation  in  PDSS  will  emerge. 

c.  Historically,  PDSS  has  not  been  addressed  explicitly  in  Army  regula¬ 
tory  documents.  Partly  as  a  result,  PDSS  has  not  been  clearly  identified  as 
a  continuing  responsibility  within  the  Combat  Developer's  role  in  the  system 
development  and  life  cycle  management  process. 

d.  Analysis  reveals  that  TRADOC  does  have  significant  PDSS  responsibilities 
that  need  to  be  fulfilled.  Effectiveness  and  readiness  of  Army  forces  will 
increasingly  depend  on  fulfilling  those  responsibilities.  They  are  itemized 

in  Figure  H ,  above. 

e.  TRADOC  is  not  currently  fulfilling  all  responsibilities  inherent  in 
its  PDSS  role,  and  cannot  fulfill  these  responsibilities  with  resources 
presently  committed  to  this  functional  area. 

f.  An  improved  PDSS  capability  is  needed  at  HQ  TRADOC  and  at  the  major 
centers  and  schools  that  have  combat  development  proponency  for  one  or  more  BAS. 

g.  The  proposed  TRADOC  Objective  PDSS  System,  which  was  defined  through 
this  study  effort,  presents  the  preferred  means  of  adequately  fulfilling  TRADOC 
PDSS  responsibilities  into  the  late  1 980 ‘ s . 

h.  The  Objective  PDSS  System  reflects  views  regarding  PDSS  held  by  the 
principal  TRADOC  centers  and  schools  and  provides  a  separately  tailored  blueprint 
which  each  such  center  or  school  can  follow  in  PDSS  implementation.  (For 
details,  see  Volume  IV,  Third  Interim  Technical  Report.) 

i.  The  PDSS  Implementation  Plan  developed  in  the  study  charts  principal 
events  necessary  to  transition  from  the  current  to  the  Objective  PDSS  System, 
within  TRAOOC.  This  Plan  covers  events  in  the  next  12  months.  Implementation 
is  seen  to  be  completely  achieved  in  1987.  (For  details,  see  Appendix  D  to 
Volume  IV.) 
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j.  Substantial  additional  resources  are  needed  to  satisfactorily  fulfill 
TRADOC  PDSS  requirements.  These  requirements,  in  terms  of  numbers  of  people, 
alone,  are  summarized  in  Figure  19,  above,  for  the  Objective  TRADOC  PDSS  System. 

k.  The  PDSS  resource  requirements  of  the  individual  TRADOC  centers  and 
schools  vary  widely.  A  detailed  discussion  of  each  BFA,  for  which  these 
resource  requirements  were  estimated,  is  presented  in  Volume  IV,  Chapter  2, 
and  provides  rationale  for  the  estimates  and  differences. 

l.  Policy  governing  TRADOC's  responsibilities  for  and  participation  in 
planning  and  providing  PDSS  for  BAS  should  be  formalized  in  a  TRADOC  regulation. 

5.  OTHER  OBSERVATIONS. 

a.  Division  in  ADP  Regulatory  authority  remains  a  problem.  Regulatory 
policy  governing  the  acquisition  and  life  cycle  management  of  automatic  data 
processing  systems  in  the  Army  is  divided  between  two  sets  of  regulations-- 
the  AR  18-series,  on  the  one  hand,  and  AR  1000-1  and  the  AR  70-series,  on 

the  other.  Problems  stemming  from  this  division  remain  despite  recent  actions 
taken  toward  clarifying  matters.  (For  additional  detail  see  pp.  18-19  above, 
and  First  Interim  Technical  Report,  p.  4-1.) 

b.  Army  Regulations  treat  post-deployment  period  too  lightly.  The 
post-deployment  period  of  the  system  life  cycle  in  general ,  and  post-deploy- 
ment  software  support  in  particular,  have  not  been  addressed  sufficiently  in 
the  basic  Army  regulations  governing  system  acquisition  and  life  cycle  manage¬ 
ment  (i.e.,  AR  1000-1,  AR  70-1,  and  AR  18-1).  (For  additional  detail  see 

p.  19,  above,  and  First  Interim  Report,  p.  4-1.) 

c.  Heavily  automated  BAS  have  complex  impact  on  training  resource 
requirements.  In  large,  heavily  automated  BAS,  training  software  is  often 
incorporated  in  the  BAS  itself  to  facilitate  operator  proficiency.  Separate, 
institutional  training  devices  also  tend  to  be  required  for  early  training 

of  operators  and  maintainers.  Automated  training  scenarios  are  often  re¬ 
quired.  BAS  changes  impact  throughout  this  chain,  creating  significant 
resource  requirements  under  the  training  side  of  TRADOC's  responsibilities. 

(For  additional  details  see  First  Interim  Report,  p.  4-2.) 

d.  Need  for  simulation  and  analysis  capabilities  highlighted  by  BAS 
experience.  Development  of  system  and  system  software  requirements  is  a 
major  TRADOC  responsibility  and  requires  detailed  insight  into  the  potential 
behavior  of  system  variables,  their  tradeoffs,  and  payoffs.  These  needs  are 
underscored  by  problems  that  have  been  experienced  with  some  BAS.  (For 
additional  details,  see  First  Interim  Report,  p.  4-2  and  4-3.) 

e.  Need  remains  for  better  way  of  stating  requirements.  One  of  the 
Combat  Developer's  principal  functions  in  the  P0SS  process  is  defining  system 
and  software  requirements  in  clear  meaningful  terms  to  the  Materiel  Developer. 
Phase  I  research  indicates  that  in  many  cases,  this  poses  serious  difficulties 
for  the  Combat  Developer  even  when  functional  requirements  are  well  known. 

(For  additional  detail,  see  First  Interim  Report,  p.  4-3.) 
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f.  Evolutionary  development  implications  need  study.  The  evolutionary 
development  procedure  authorized  under  Paragraph  13  of  DODI  5000.2  carries 

a  number  of  implications  that  need  to  be  considered  with  respect  to  configur¬ 
ation  control,  post-deployment  support,  training  requirements,  and  other 
related  areas. 

2  2 

g.  Hierarchy  of  configuration  control  boards  needed  for  CCS  .  The  CCS 
(formerly  EOS'")  concept  for  battlefield  automation  and  the  requirement  for 
interoperability  among  BAS  within  this  concept  appear  to  make  the  establish¬ 
ment  of  a  hierarchy  of  conf iguration  control  boards  desirable.  (For  further 
details,  see  First  Interim  Report,  p.  4-4.) 

h.  Satisfaction  of  PDSS  skill  requirements  may  call  for  special  steps. 

The  types  of  skills  needed  for  BAS  PDSS,  the  quantity  of  people  required,  and 
the  anticipated  shortage  of  critical  skills  suggest  that  attention  needs  to 
be  given  to  ways  of  solving  a  potentially  difficult  problem.  (For  additional 
detail,  see  First  Interim  Report,  p.  4-5.) 

i .  Grade  level  ceilings  at  TRADQC  centers  &  schools  may  need  revision. 
Difficulty  has  been  experienced  at  some  TRADOC  schools/centers  in  obtaining, 
retaining,  and  motivating  skilled  civilians,  particularly  in  the  GS  12  range. 
At  these  locations,  existing  grade  ceilings  allow  little  or  no  room  for 
promotion  above  GS  12.  Unless  corrective  action  is  taken,  this  difficulty 
may  seriously  impede  implementation  of  needed  PDSS  plans.  Having  spaces 
authorized,  alone,  does  not  solve  the  manpower  problem. 

j .  Testing  needs  of  PDSS  do  not  fit  some  interpretations  of  DODD  5000.3. 
Paragraph  D.6.c.  of  DOD  Directive  5000.3,  Test  and  Evaluation,  states  that, 
"Before  release  for  operational  use,  software  developments  for  either  new 

or  existing  systems  shall  undergo  sufficient  operational  testing  as  part  of 
the  total  system  to  provide  a  valid  estimate  of  system  effectiveness  and 
suitability  in  the  operational  environment."  This  statement  has  apparently 
been  interpreted  by  some  personnel  at  the  US  Army  Operational  Test  and 
Evaluation  Agency  (OTEA)  and  at  HQ  TRADOC  to  mean  that  Operational  Test  II 
must  be  conducted  following  every  modification  to  system  software.  This 
interpretation  has  resulted  in  the  conduct  of  some  tests  that  go  beyond 
those  considered  to  be  required  by  other  members  of  the  Combat  Developments 
Community.  This  subject  area  needs  to  be  addressed  jointly  by  TRADOC,  DARCOM, 
and  OTEA  to  ensure  that  unnecessary  testing  is  not  conducted  (thus  causing 
unacceptable  delays)  and  that  there  is  common  agreement  regarding  respon¬ 
sibilities  for  testing  software  modifications. 

k.  Responsibility  for  determination  of  training  device  requirements 
not  clearly  placed.  TRADOC  Reg.  10-41  does  not  clearly  place  responsibility 
for  determination  of  training  device  requirements  in  either  the  Training 
Developments  or  Combat  Developments  arenas  (TRADOC  Reg.  10-41,  page  4).  This 
ambiguity  appears  to  be  reflected  at  some  TRADOC  schools,  with  a  resulting 
danger  that  unnecessary  delays  may  occur  in  proper  recognition  and  definition 
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of  such  requirements.  Because  of  the  impact  that  BAS  may  have  on  resource 
requirements  (Paragraph  c.,  above),  such  delays  could  be  serious  in  terms  of 
costs  and  combat  readiness.  Clarification  of  this  responsibility  appears 
desirable,  and  may  also  improve  cooperation. 

l.  TRADQC  Reg.  71-12  needs  to  be  reviewed.  TRADOC  Reg.  71-12  establishes 
policies  governing  the  Total  System  Management  process  within  TRADOC  and 
implements  the  TRADOC  System  Manager  (TSM)  concept.  There  have  been  instances 
when  local  interpretation  of  this  regulation  has  resulted  in  conflicts  with 
respect  to  responsibilities  of  the  TSM  as  opposed  to  those  of  the  Directorate 
of  Combat  Developments.  This  observation  indicates  a  need  to  examine  the 
provisions  of  TRADOC  Reg.  71-12  with  a  view  toward  determining  if  any  revision 
is  needed  to  clarify  responsibilities  in  this  functional  area. 

m.  Standardized  software-problem  report  forms  are  needed.  The  PDSS 
Concept  Plan  for  BAS  identifies  the  review  of  these  forms  for  possible 
standardization  as  an  area  requiring  action  during  implementation  of  the  plan. 
This  requirement  is  repeated  here  to  emphasize  the  importance  attached  to  it 
by  elements  of  the  Combat  Developments  Community. 

n.  TRADQC  centers  &  schools  need  to  prepare  detailed  PDSS  implementation 
plans.  Individual  TRADOC  centers  and  schools  need  to  prepare  detailed  plans 
for  PDSS  implementation  at  their  respective  locations,  based  on  the  general 
plan  formulated  in  this  study  effort. 

o.  Computer  resource  implications  need  to  be  examined  TRADOC -wide.  A 
number  of  questions  have  arisen  during  this  study  effort  concerning  computer 
resources  for  PDSS  and  other  purposes  in  TRADOC.  Among  these  questions  are 
issues  of  computer  needs/workloads,  types,  locations,  costs,  resource  sharing, 
procurement,  and  trends  involved.  A  TRADOC-wide  examination  of  these  issues 
and  their  implications  appears  needed. 

p.  Audit  trail  data  for  predicting  optimum  allocation  of  resources  is 
lacking.  This  study  found  little  data  on  PDSS  experiences  within  TRADOC  that 
was  useful  for  quantitatively  predicting  the  optimum  allocation  of  combat 
developer  resource  requirements  over  the  system  life  cycle.  An  effort  should 
be  made  to  collect  data  reflecting  experiences  and  lessons  learned  on  a  system 
by  system  basis  to  support  future  resource  requests  and  allocations  and  other 
planning,  programming,  and  budgeting  actions. 

q.  Multiplicity  of  BAS  hardware  types  and  software  languages  remain 
complicating  factors.  The  current  multiplicity  of  BAS  hardware  and  software 
languages  will  remain  complicating  factors  in  training,  logistics,  and  PDSS 
well  after  the  introduction  of  the  Ada  language  and  the  military  computer 
family  (MCF). 

r.  Early  analysis  can  reduce  PDSS  and  other  system  problems.  Early 
analysis  of  software  sensitivity  and  flexibility  to  changes  in  the  threat, 
doctrine,  and  tactics,  if  appropriately  reflected  in  system  software  design, 
can  reduce  later  POSS  and  other  system  problems. 
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s.  Crisis/wartime  PDSS  requirements  may  require  special  measures.  The 
PDSS  Concept  Plan  for  BAS  addressed  the  flow  of  PDSS  problems  and  solutions 
through  the  generalized  software  support  model  for  PDSS,  to  include  crisis/ 
wartime  support  response.  The  importance  and  criticality  of  crisis/wartime 
support  and  the  nature  of  certain  situations  or  requirements,  may  necessitate 
that  special  measures  be  adopted  for  providing  PDSS  and  that  procedures  to 
be  employed  be  tailored  to  the  immediate  circumstances.  Such  requirements  \ 

must  be  addressed  jointly  by  the  MD,  CD,  and  User  on  a  system-by-system  basis 
to  ensure  that  proposed  solutions  are  feasible  and  tailored  to  best  satisfy 
the  User  needs. 

6.  RECOMMENDATIONS.  Whereas  the  Commanders  of  DARCOM  and  TRADOC  have 
approved  the  PDSS  Concept  Plan  for  BAS,  as  initial  steps  in  implementing 
that  plan  within  TRADOC,  it  is  recommended  that  TRADOC: 

a.  Adopt  the  proposed  Objective  PDSS  System. 

b.  Approve  the  implementation  plan  as  set  forth. 

c.  Publish  the  implementing  regulation  and  modify  such  other  regulations 
as  necessary. 


